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Vote: 


Summary of Voting on SC 2 N 3302 


Q1: Do you support the addition of the subproject to the Programme of Work of SC 2? 


Yes: 15, Yes with comment: 1, No: 3 


Participation: 


Q2: Do you commit yourself to participate in the development of this subproject? 


Yes: 5 


Q3: Are you able to offer a project editor who will dedicate his/her efforts to the advancement and 


maintenance of this subproject? 


Yes: 2 
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Attachment 1 - Canada 
Q2: Canada - Can participate in coding related matters 
Editorial: 


Either remove "1-16" in the first sentence in Annex A, section A.1, or change it to "parts 1-4, 
9, 10, 13-16". 


Reasons: 


In Annex A, section A.1, the first sentence reads: "The following parts 1-16 of ... based on the 
Latin alphabet." Only parts 1-4 and parts 9, 10, 13-16 are listed. 


In section A.2, the first sentence reads: "The following parts of ... other than the Latin 
alphabet". Parts 5-8, and 11 are listed here. 


While it is true that all 8859-x contain Latin alphabets, the two opening sentences in A.1 and 
A.2 can be confusing. It's best to remove "1-16" in A.1 from the opening sentence in A.1 or 
to change it to "1-4 and parts 9, 10, 13-16", which is very clumsy. 


Attachment 2 - Finland 


Q1: In our discussions with the Swedish National Body we have come to the conclusion that 
their stated reasons are equally applicable to us. 


Attachment 3 - Ireland 
Regarding ISO/IEC JTC1/SC2 N3302 ballot, closing date 1999-06-30: 


Title: Subdivision Proposal on JTC 1.02.20 for 8859-16, 8-bit single-byte coded graphic 
character sets -- Part 16: Latin Alphabet No. 10 


Q.1 Do you support the addition of the subproject to the programme of work of SC2? 
Ireland votes Yes with Comments. 


While in general Ireland does _not_ favour the addition of many new work items involving 8- 
bit character sets, it is clear to us that this project subdivision is a natural part of Romania's 
intention to deprecate the use of U+015E, U+015F, U+0162, U+0163 (or the base Latin 
letters plus U+0327) for writing Romanian in favour of the preferred use of U+0218, U+0219, 
U+021A, U+021B (or the base Latin letters plus U+0326). 


Since data encoded in ISO/IEC 8859-2 maps to the former set of characters in ISO/IEC 
10646, it seems a logical part of Romania's migration policy to recode data from ISO/IEC 
8859-2 to the new ISO/IEC 8859-16 which will map to the latter set of characters in ISO/IEC 
10646. It is assumed that Romania has assessed the costs of making such a migration and that 
this new part of ISO/IEC 8859 should be accepted in order to assist the Romanians. 


In addition, like ISO/IEC 8859-13 does for Lithuanian and Latvian, the proposed ISO/IEC 
8859-16 contains preferred Romanian quotation marks as well as the euro sign and integral 
French characters, and is generally a superior 8-bit code table to meet Romanian 
requirements. 

Q.2 Do you commit yourself to participate in the development of this subproject? 


Yes, Ireland commits to participation in the development of this subproject. 


Q.3 Are you able to offer a project editor who will dedicate his/her efforts to the advancement 
and maintenance of this project? 


Yes, Michael Everson of Everson Gunn Teoranta, who was project editor of ISO/IEC 8859-14 
and assistant editor of ISO/IEC 8859-15, has offered to prepare the text. He has been asked to 
do so by IRS, Institut Roman de Standardizare. 

Attachment 4 - Japan 

Q1: It would be appreciated by Japanese national body if proceeding to NP process is 
considered for this proposal. (to avoid unnecessary question from JTC 1) 

Attachment 5 - Romania 


Q3: Michael Everson 


Attachment 6 - Sweden 

1. Swedish position on Project Subdivision for Romanian code set 

The Swedish NB fully recognizes the Romanian needs for correct naming of the letters S and 
T WITH COMMA BELOW, as different from S and T WITH CEDILLA, in character coding 
standards. 

However the Swedish NB has some doubts whether the proposed new part of ISO/IEC 8859, 
as documented in JTC 1/SC 2 N3302, is the best solution to this character identification 
problem. It appears that some further work should be performed to determine exactly how the 
Romanian needs are best satisfied. 

The Swedish NB therefore disapproves of the proposal for a Project Subdivision according to 
N3302, but will — if so desired — participate in continued other work on the matter. 

2. Reasons for Swedish position 


There are three main reasons for the Swedish disapproval. 


2.1 Existing partial solution 


In the view of the Swedish NB, new parts of ISO/IEC 8859 should be created only when user 
requirements can not be satisfied in any other way. Also it is most desirable that any new part 
can be based on a stable and implemented scheme. 


In the latest revision of ISO/IEC 8859-2 the Romanian character identity problem was 
recognized, and text was introduced stating that the S and T WITH CEDILLA can be used to 
represent S and T WITH COMMA BELOW. This was intended as a formalization of existing 
actual practice. 


This 8859-2 solution will naturally cause problems if it is required to differentiate in data 
processing between S WITH CEDILLA, as used in Turkish, and S WITH COMMA BELOW, 
as used in Romanian (T WITH CEDILLA appears to not be used in any major language, and 
differentiation from T WITH COMMA BELOW should therefore not be needed). 


The need to differentiate between the two S variants has previously been mentioned in 
discussions. Since however the S WITH CEDILLA is not included in the proposed 
Romanian new part, such differentiation is obviously not needed in Romania. 


2.2 Possibility of part 2 modification 


A simple solution to the identity problem would be to change the identification of the two 
letters in ISO/IEC 8859-2 (and reverse the text about alternative use, stating that S and T 
WITH COMMA BELOW can be used to represent S and T WITH CEDILLA). 


Sweden is aware of the stated position of SC 2 to not change established code set standards 
technically. An exception to this position should however be considered, since A) it appears 
that the original coding was based on a misunderstanding and B) no serious effects should 
result from a changed identification, the glyphs being practically identical, and Romania 
being the only country directly concerned (Turkey, with the letter S WITH CEDILLA, uses 
ISO/IEC 8859 part 9, not part 2). 


2.3 Suitability of proposed coding scheme 


It could appear natural that a new coding scheme for Romania would be based on ISO/IEC 
8859-2, with the problematic S and T WITH CEDILLA exchanged for letters WITH 
COMMA BELOW. This would insure an acceptable automatic "fall-back presentation" if data 
was transferred from a system based on the new scheme to another still using ISO/IEC 
8859-2, and vice versa. 


The proposed scheme is however completely different from the ISO/IEC 8859-2 (obviously 
being based on the new ISO/IEC 8859-15 instead). It seems this could cause difficulties in 
installations adopting the proposed scheme, both in communication with other installations 
and in "legacy applications". 


Further the proposed scheme has a smaller language coverage than ISO/IEC 8859-2, not 
satisfying Czech, Slovak and Sorbian needs; covering French instead. Although this matter 
has naturally been carefully considered by Romania, the Swedish NB thinks it unfortunate 
that the language coverage has been reduced as compared to part 2, since this may make the 
acceptance of the scheme more problematic. 


The present ISO/IEC 8859-2 contains several diacritical signs, most of which should have 
insignificant - if any - use as free-standing characters. It seems that the possibility of 
exchanging diacritical signs for the specifically French letters should first be considered if a 
completely new part is designed, and complete coverage of French is essential. 


Attachment 7 - USA 
The U.S. vote is to DISAPPROVE. The reasons for disapproval are as follows: 


The recommends to use ISO 10646 or ISO 8859-2, unless a marketing requirement for the 
repertoire of ISO 8859, part 16 is proven. 


